Développement efficace avec Rstudio

Travail collaboratif avec R

1 Pourquoi utiliser Rstudio?

Rstudio est un éditeur de code (IDE) très complet, le plus intégré à l’éco-système R:

• Outils pour écrire et exécuter du code R
• Extensions pour écrire des documents facilement à partir de R markdown: documents LateX, html, livres…
• Possibilité d’exécuter d’autres langages (Python,C++…)
• Brancher à git, visualiser du html, des shiny…

L’interface a l’aspect suivant¹:

1. La fenêtre source: fenêtre où on édite les programmes et fichiers texte.

2. La fenêtre console: fenêtre où le code édité s’exécute. On peut également écrire directement dans la console pour exécuter du code.

3. La fenêtre Files/Plots/….
   • Files: Naviguer dans les fichiers
   • Plots: Affichage des graphiques
   • Packages: Liste des packages installés et disponibles
   • Help: Aide des fonctions, ex: ?sum
   • Viewer: affichage de pages HTML, de documents markdown compilés
4. La fenêtre Environment/History/…..
   • Environment: affichage des objets appartenant à l’environnement global de R
   • History: historique des commandes exécutées
   • Connections: connection entre R et d’autres systèmes, par exemple serveur SQL
   • Et des onglets optionnels:
     • Git: contrôle de version, sur lequel nous reviendrons
     • Build: onglet pour la compilation de packages, nous reviendrons également dessus

2 Utiliser des projets R

2.1 Principe

Pour qu’un programme soit reproductible, le contexte doit être homogène, c’est-à-dire que tout utilisateur doit être en mesure de faire tourner l’intégralité du programme sans erreur. C’est une philosophie assez exigeante mais qui, lorsqu’on l’a à l’esprit, permet de développer un code propre et clair facilitant une évolution future (le code ne doit jamais être vu comme une production figée).

Les projets Rstudio sont un outil pour faciliter la collaboration mais aussi mieux s’organiser lorsqu’on travail en solitaire. Un projet bien organisé facilite la vie:

• Centraliser l’ensemble des productions d’un projet: codes, articles, présentations, documentation…
• Faciliter la compréhension et la reproducibilité d’un travail à partir de 0
• Permettre l’interaction entre les fichiers (plusieurs documents codes, R markdown…) et avec les données

• Faciliter des évolutions postérieures avec un projet organisé

• Un projet ne contient pas que du code R:
  • ensemble des documents (documation incluse) pour permettre la compréhension et l’exécution d’un projet

La philosophie des Rproject est d’associer à chaque projet personnel un contexte

• Chaque projet a un contexte: espace de travail, historique de commandes, variables d’environnement…
• Projet: pas seulement fichier .R mais un ensemble plus global

Par exemple, le package ci-dessous est organisé de manière à ce que les codes (R) soient associés à une documentation propre à chaque fonction (man) et à une documentation plus globale (inst). L’organisation des packages sera abordée plus en détail par la suite. Ce package est lui-même inclus dans un projet plus large où il est appelé par des Rmarkdown qui me permettent de construire des productions écrites intermédiaires et finales

Exemple de RProject (ici sous forme de package)

2.2 Créer un projet R

Créer un nouveau projet: File > New Project

3 possibilités:

1. Dans un nouveau dossier:
   • Pour un projet tout nouveau
2. Dans un dossier existant:
   • Commencer à organiser un projet dans lequel des documents ont déjà été produits
3. Cloner un projet depuis un dépôt:
   • Pour récupérer depuis un dépôt git distant et se connecter à celui-ci
   • Nous verrons cela plus tard

2.3 Types de projets possibles

Rstudio facilite l’initialisation de différents types de projets. Cela permet d’avoir une organisation cohérente avec le besoin: écrire un article/livre avec R ne demande pas la même organisation de programmes qu’une chaîne de production

Différents types de projets

On peut tout à fait avoir des projets emboîtés si c’est nécessaire. Par exemple, une organisation fréquente d’un dossier est

• Un projet maître qui centralise des sous-projets:
  • Un ou plusieurs ensembles de fonctions qui ont été homogénéisés sous forme de package
  • Un dossier stockant des exploitations de ces fonctions, par exemple des articles ou rapports

Les projets sont une forme très malléable d’organisation et s’adaptent ainsi facilement à des besoins hétérogènes. Ils sont néanmoins recommandés, à défaut de pouvoir les rendre obligatoire, pour travailler en équipe où la définition d’un contexte commun est primordial

2.4 A la création du projet: intégrer git ?

Un outil supplémentaire pour assurer la sécurité du code est le contrôle de version. Cela permet de stocker un code, et l’ensemble de ses évolutions, sur un serveur distant. Par exemple, le projet ci-dessous,

Un exemple de projet sauvegardé

est entreposé sur un dépôt. Il en existe des publics (gitlab,github,framagit) et des dépôts à accès restreints (ex: plateforme innovation). Le principal intérêt de la gestion de version est que, ligne par ligne, on peut suivre les évolutions d’un fichier. En conséquence, plus besoin de stocker 20190513_toto.R et 20190514_toto.R: on aura un seul fichier toto.R dont on peut suivre les version.

Le principal logiciel de gestion de version est git, sur lequel nous reviendrons. On peut initialiser git en même temps que le projet

• Ou l’initialiser à tout moment (cf. suite)
• Ou initaliser le projet à partir d’un dépôt git existant (plus simple, cf. suite)

To git or not to git?

2.5 RProject: structure

1. Création d’un fichier .Rproj dans le dossier principal.
   • Centralise les options (présentées dans la suite)
   • Raccourci pour ouvrir le projet

Structure d’un projet R

2.6 RProject: structure

2. Création d’un dossier caché (nommé .Rproj.user)
   • Où sont stockés les fichiers temporaires du projet (scripts sauvegardés automatiquement…)
   • Automatiquement ignoré par .Rbuildignore, .gitignore

Structure d’un projet R

2.7 RProject: structure

3. Charge le projet dans Rstudio et affiche son nom dans la barre de projets

Raccourci pour accéder aux derniers projets

3 Travailler sur un projet

3.1 A l’ouverture d’un projet

Lorsqu’on ouvre un Rproject:

• Une nouvelle session R est ouverte
• Le .Rprofile du projet (si présent) est chargé
• Le .RData du projet (si présent) est chargé (si les options du projet l’autorisent)
• Le .Rhistory du projet (si présent) est chargé dans le cadre History (et permet l’utilisation des boutons haut/bas pour remonter l’histoire des commandes).
• Le working directory est fixé au niveau du dossier maître du projet
• Les documents précedemment ouverts sont restaurés dans l’éditeur Rstudio
• Les autres paramètres RStudio (e.g. position du curseur, etc.) sont restaurés à leur valeur précédent la fermeture du projet

3.2 A la fermeture du projet

• .RData et/ou .Rhistory sont sauvegardés dans le projet (si les options du projet l’autorisent)
• Les documents ouverts non sauvegardés sont sauvergardés temporairement
• Les autres paramètres RStudio sont sauvés
• La session R associée au projet est arrêtée

4 Options du projet (Tools > Project Options...)

4.1 Options générales

• (Default): utiliser les options globales
• Restore .RData into workspace at startup — N’est pas recommandé si les données sont volumineuses (ralentissement du démarrage de la session)
• Always save history (even when not saving .RData) — Ajouter la ligne .Rhistory dans le fichier .gitignore (si existe) si l’histoire des commandes est conservée

Options générales

4.2 Options build (développement package uniquement)

C’est l’endroit où on peut définir les options de compilation du package. Nous reviendrons dessus plus tard. Il est recommandé de cocher les cases

• Use devtools package functions if available: permet d’utiliser l’outil devtools pour créer le package
• Generate documentation with Roxygen: permet d’automatiser la création des fichiers de documentation à partir du package Roxygen

On peut ajouter des options à la compilation. Par exemple, pour gagner du temps, on pourra utiliser l’option --no-build-vignettes qui évite de re-compiler les vignettes (qui peuvent mettre du temps à compiler si elles sont longues)

Exemple d’options pour les packages

4.3 Options git

Exemple d’options git

5 Edition de code dans Rstudio

5.1 Raccourcis utiles

Pour gagner du temps, il est important d’utiliser les raccourcis pour les commandes répétitives. En voici quelques uns,

• Ctrl+Enter: exécuter les lignes sélectionnées
• Tab: autocomplétion
• Ctrl + Alt + R: exécuter l’ensemble d’un script
• Ctrl + I: réindenter code
• Ctrl + Shift + A: reformater code
• Alt + Up/Down: déplacer une ligne sans faire copier-coller
• Ctrl + Deplacement souris: passage en édition verticale (curseur en colonne)
• Ctrl + Shift + M: insérer pipe %>%
• Alt+ 6 (windows): insérer opérateur assignation <-
• Ctrl + Shift + F: rechercher une expression dans plusieurs fichiers
• Ctrl + Shift + K: compilation d’un markdown (knitter en bon français)

6 Utiliser le debuggeur

6.1 Erreur: toutes ne sont pas à effacer

Une fonction peut provoquer une erreur parce que

1. C’est volontaire: on introduit des stop pour éviter l’exécution d’une erreur dans des conditions que l’on n’avait pas anticipé. C’est très utilisé en programmation défensive, paradigme de programmation où on essaie d’assurer le fonctionnement continu d’un programme, en faisant en sorte qu’un code échoue dans une manière pré-determinée même si l’origine de l’erreur ne pouvait pas être anticipée lors de la conception. Un des principes clés de ce paradigme est “l’erreur rapide”: dès qu’on remarque une potentielle erreur, on la signale. Cela implique plus de travail pour le programmeur mais rend le débuggage, et donc la collaboration, plus efficace car les utilisateurs peuvent identifier et isoler l’origine de l’erreur et ainsi la corriger plus rapidement.

Par exemple, si on ne connaît pas le fonctionnement de la fonction log, et donc ne saît pas qu’elle fonctionne (mais renvoie un NaN) avec des nombres négatifs, on peut une pratique de programmation défensive et écrire

lance_erreur <- function(x){
  if (x<=0) stop("J'ai peur que les nombres négatifs provoquent une erreur")
  
  return(log(x))
}
lance_erreur(2)

## [1] 0.6931472

lance_erreur(-2)

## Error in lance_erreur(-2): J'ai peur que les nombres négatifs provoquent une erreur

La programmation défensive n’est pas une pratique obligatoire en équipe, il s’agit d’un principe de prudence.

2. C’est involontaire: un comportement non anticipé d’une fonction, une erreur de type de variable… Il s’agit de cas fréquents. Dans ce cas, le principe général est d’essayer d’identifier l’erreur à partir de cas types (les tests d’un package visent à automatiser cette recherche) pour être en mesure d’améliorer progressivement une fonction.

On peut utiliser trois outils pour débugger:

1. Inspecteur d’erreur Rstudio et traceback() qui liste la séquence des appels qui a amené une erreur
2. L’outil “Rerun with Debug” et la commande options(error = browser) permettant d’ouvrir une fenêtre interactive pour tester l’environnement ayant généré l’erreur
3. Les points de débuggage (breakpoints) ou la commande browser() qui ouvre une session sur un point déterminé par le créateur de la fonction

6.2 Traceback

Cet outil est parfois appelé call stack. Il permet de voir l’empilement d’appels de fonctions ayant généré l’erreur.

Par exemple, voici une séquence ayant générant une erreur

f <- function(a) g(a)
g <- function(b) h(b)
h <- function(c) i(c)
i <- function(d) "a" + d
f(10)

En cliquant sur le bouton traceback, on voit la séquence de fonctions, ce qui permet d’identifier que l’origine de l’erreur provient de la fonction i(.):

S’il s’agit d’un code qui a été lu à partir de la commande source(), le traceback affichera également la localisation de la fonction dans le fichier sous la forme filename.r#linenumber. On peut cliquer dessus et Rstudio amènera à la localisation du fichier dans l’éditeur

6.3 “Rerun with debug”

traceback() montre la manière dont l’erreur s’est produite, pas pourquoi. Cliquer sur le bouton “Rerun with debug” permet d’ouvrir une fenêtre interative qui permet de mettre en pause l’exécution d’une fonction et explorer interactivement l’état de celle-ci.

C’est particulièrement intéressant car une source fréquente d’erreur provient du fait que, lorsqu’on développe généralement un code, on interagit avec l’environnement global alors que les fonctions exécutent leur code interne dans un environnement séparé. Le debuggeur permet d’interagir avec ces environnements, de s’assurer que l’environnement accède bien aux objets désirés (packages, paramètres, dataframe, functions…), que les environnements emboîtés accèdent bien aux objets attendus…

Vous verrez apparaître le code correspondant dans l’éditeur, avec la prochaine commande mise en lumière. Les objets présents dans les environnements d’exécution des différentes fonctions emboîtées sont disponibles: on peut naviguer dedans.

On dispose également d’une barre dans la console:

• Next: exécuter la prochaine étape de la fonction. Attention, si vous disposez, dans la fonction, d’une variable nommée n: pour l’afficher, vous devrez utiliser print(n) (dans le debuggeur, n est un raccourci pour next).
• Step into: fonctionne comme next mais si la prochaine ligne est une fonction, cela vous enverra dans la fonction afin de progresser ligne par ligne
• Finish: finit l’exécution de la boucle ou fonction actuelle
• Continue: retour à l’environnement supérieur. C’est utile si le problème sur la fonction a été réglé et qu’on veut tester s’il est bien corrigé
• Stop: sortir du debuggeur

6.4 Breakpoint

On peut mettre un point d’arrêt à une fonction en cliquant sur la gauche du numéro de ligne d’un script (ou Shift + F9 quand on a le curseur sur la ligne) ou bien browser() dans le code de la fonction à l’endroit où on désire l’arrêter. Une fois placé, quand on exécutera la fonction, on aura le debuggeur qui s’ouvrira une fois arrivé à cet endroit

7 Addins Rstudio

7.1 Addins

Les addins sont des outils pratiques pour gagner du temps dans l’édition du code

• Installation simple grâce à addinslist: install.packages('addinslist')
• Ceux sur CRAN sont disponibles pour tous, ceux sur github nécessitent d’avoir configuré le proxy
• Génèrent automatiquement du code ou du texte utile pour les markdown

Les addins sont disponibles en haut de l’éditeur

Addins Rstudio

Avec le package addinslist, on peut installer des addins à partir d’une fenêtre graphique

Installer facilement de nouveaux addins

7.2 Quelques addins utiles

• snippetsaddins: convertir slash automatiquement pour avoir des chemins valide
  • “monchemin/toto/fichier.csv” -> “monchemin\toto\fichier.csv”
• ggedit: aide pour générer un code pour graphiques ggplot2
• JADD: en sélectionnant une fonction, on assigne les paramètres par défaut dans l’environnement
• questionr: recodage facilité des variables factor
• trackmd: un outil de track change pour markdown

7.3 Cheatsheets

On peut trouver des aides mémoires en ligne grâce aux cheatsheets. Celle relative à Rstudio est disponible ici

8 Annexe

8.1 Rhistory

---

1. Pour vos yeux fragile, je vous recommande de changer l’aspect de Rstudio pour mettre un fond noir, moins violent 😄. Pour changer le fond, on peut utiliser Tools > Global Options > Appearance↩